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(54) Secure ffle system 

(57) A method and apparatus that allows a conpu- 
ter system to trust both program and data files without 
the iriterventton of the user and without the possIbSIt/ of 
drcuTiventing the model of trust A ffle system incorpo- 
rates two levels of vaTtdalion for programs and data. A 
first level of validation spectfles sources thai the user 
has deckled are trustworthy or urrtrustworthy. A second 
le^el of validation specifies sources that the system 
itself considers trustworthy or untrustworthy. For data to 
be acceptable, rt must be acceptable to both levels of 
checWng. In addition, both the user and the system can 
specify multiple acceptable signatures and further 
allows various ones of the multiple sigrwtures to have 
different levels of access to the system. 
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Description 

RELP OF THE INVENTION 

TWs application relates to operating systems and, 
more particulaily, to a file system that vafidates an entity 
attafDpting a fda access before altowing the entity to 
perform file operations. 

BACKGROUND OF THE INVENT10M 

In recent years, the Internet has become extremely 
popular. Using the internet, users can download f Pes 
into the memory of their convuters easily and cheaply. 
One problem with such a process is that the user has no 
way of knowing whether the party sif^plying the soft- 
ware is trucfiA^onhy. Software suppHed from untrusted 
sources can contain une)q3ected "bugs" and might even 
be completely different from the software flia user 
expects to receive. Fbr ocanrple, software from 
untrusted sources may contain a conputer virus that is 
not detected until the software is executed. 

In fact such problemc can arise with any software 
or data obtained from outside sources. Computer pro- 
grams arKi computer data files are normally stored on 
conputer systems wfthout the capaWnty of automati- 
cally ensunng that programs and data are 1) authentic 
and 2} unmolested. Conventional methods of checlgng 
fbr authenticity and nonconxiption require action on the 
pari of human beings. Application programs verify data 
by fbced checksums, both with ar^ without crypto- 
graphic assurance. What »s needed is a tAily automatic 
and transparent method of checking arxl authenticating 
software and data in a computer system. 

SUMMARY OF TMg INVgNTtOM 

The present invention overcomes the problems and 
disadvantages of tiie prior art b/ ^oviding a method 
and apparatus that allows a computer system to trust 
boti^ program and data files without the intervention of 
the user and wHh a decreased pos^ Wty of drcunnvenl- 
ing the model of trust 

A preferred embodiment of the present Invention 
includes twvo levels of validation fbr programs and data. 
A first level of validation specifies sources that the user 
has decided are trustworthy (or not tmstworthy). A sec- 
ond level of vaTtdation specifies sources that the system 
itself considers trustworthy or untrustworthy For data to 
be acceptable, it nuist be acceptable to bc^ levels of 
chedQng. Thus, for example, if the user decides to 
accept all data from entity "A*, but the system has 
decided not to accept alt data from entity 'A,' the file 
system would not Store data from entity "A." As a further 
exanrple, if tiie user has decided to accept no data firom 
"B", but the system has decided to accept alt data from 
"B*. then no data from "B" would be stored on the sys- 
tem. 



in addition, a preferred embodiment of tiie present 
invention allows the user and the system to specify mul- 
tiple acceptable signatures and furtiier allows various 
ones of tiie multiple signatures to have different levels of 

5 access to the system (i.e., different permissions). A pre- 
ferred efTA>odtment the present invention can be imple- 
mented 60 as to be transparent to the user and to co- 
e»st with existing fSe systems. 

In accordance with the purpose of the Invention, as 

10 ambcdied and broadly described herein, a preferred 
embodiment of the present invention is a method of per* 
fomiing a file access, comprising the steps, performed 
by a data processing system having a memory, of: 
receiving an rnctication that an entity desires to perform 

15 a file access operation on a file of the data processing 
system; obtaining an afftdavft of tiie ftle; checking that 
tiie affidavit is acceptable in accordance with a user sig* 
nature data structure stored in the memory; checking 
tiiat tiie affidavit is acceptable in accordance writii tiie 

£0 system signature data structure stored in the memory; 
and allowing the file access operation when the affidavit 
is acceptable in accordance with both the user signa- 
ture data structure and the system agnature data struc- 
ture. 

S5 In fizrther accoidance witii the purpose of 9ie inven- 
tion, as embodied and broadly described herein, a pre- 
ferred embodiment of tiie presem invention is a method 
of creating a secure file, conprising the steps, per- 
formed by a data processing system having a memory, 

30 ot receivir^ an Indication that an entity desires to per- 
fomi a file access operation on a file of tiie data 
processing system; obtaining a private key of tiie entity; 
receiving data of the file to be aeated; determinmg a 
checksum of the file; encrypting tiie checksum using the 

s$ private key; and creating the file and an associated affi- 
davit that Includes the encrypted checksura 

In further accordance votii tiie present invention, as 
emboded and broadly descn'bed herein, a preferred 
embodiment of the present invention is: a signature 

40 data structure stored in a memory of a data processing 
system, comprising: a first entity field storing a name of 
an entity trusted to perform a f ae access; a fust pKjtM 
key field storing a public key of the first entity: a second 
entity field storing a name of an entity trusted fo perform 

45 a ftle access; and a second public Key fl^d storing a 
public key of the second entity. 

Advantages of the invention vrill be set forth in part 
In tiie description which folkiws and In part will be obvi- 
ous from the descHption or may be learned by practice 

60 of the invention. Advantages of the invention w3l be real- 
ized and attained by a combination of the elements par- 
ticularly pointed out in the appended claims and 
equivalents. 

SS BRIEF DES CTlp-nON OF THE HGURES 

The accompan^ng drawings, which are incorpo- 
rated in and constitute a pan of this specification, illus- 
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trate $ov6/al embocnments of the inventSon and. 
together with th« description, serve to explain Ihe princi- 
ples of the hvent'on. 

Fig. 1 a bbdc diagram d a computer system In 
accordance with a prefenred en^^iment of the present 
invention. 

Rg. 2 is a block diagram showing a data flow of a 
preferred embodiment of the present Invention. 

Fig. 3 shows an example of a user signature data 
structure or a system signature data structure cf Rg. 1 . 

Rgs. 4{a) and 4(b) are flow charts showing how 
files are checked against the user stgnature data and 
the system signature data 

Pig. 5 is a flow chart of steps used to create signed 
fUes In a preferred embodiment of the present invention. 

Fig. 6 is a block diagram of another prefen-ed 
embodiment off the present invention in which the m^or- 
ity of the operating system must be verified before the 
system can be booted. 

DETAILED DESCRIPTTOM QF THE PREFgRRFD 
EMBODIMENTS 

Reference wKI now be made bi detail to the pre- 
ferred errexKJiments of ttie Inventionr examples of which 
are illustrated in the accompanying drawings. Wherever 
possible, the same reference numbers will be u^ed 
throughout the drawings to refar to thd same or tike 
parts. 

Fig. 1 is a bbck diagram of a computer system 100 
in accordance with a preferred embodiment of the 
present invention. Computer system 100 is connected 
to line 106* wfiich can be, for example, a LAN, a WAN, 
or an internet connection. Line 106 can also represent a 
wireless connection, such as a cellular network connec* 
tion. 

Computer system 100 includes a CPU 102; a pri- 
mary storage 104; input^output lines 105; an input 
device 150. such as a keyboard or mouse: and adisplay 
device 160. such as a display terminal. Primary storage 
104 can include any type of computer storage including, 
without limitation, random access memory (FUM). read- 
only memory (ROM), and storage devices which inckJde 
magnetic and optical storage media such as magnetic 
or optical disks. Computer system 100 further includes 
an input dsvfce 161 for reading a compute usable 
medium 162 having conputer readable program cede 
means embodied therein. Input device 161 Is, tor exam- 
ple, a disk drive. 

Primary storage 104 includes a data stoictitfe izd 
containing user signatures and a data structure 122 
containing system signatures, as discussed below in 
connection writh Fig. 2. Memory 104 also includes sig- 
nature checking software 124. which ts also discussed 
t>elow. 

A person of ordirwy skill in the art will understand 
that menDory 104 also contains addrtional information, 
such as application programs, operating systems, data. 



etc.. which are not shown in the figure for the sake of 
dartty. It will be understood by a person of ordinary skill 
in the art that conr\puter system 100 can ateo include 
numerous elements not shown in the figure for Ihe sake 

5 of cJanty, such as additional disk drives, keyboards, dis- 
play devices, netAwk connecttons. additional memory 
additional CPUs, LANs, bput^output tines, etc. A pre^ 
fenred embodiment of the invention runs under the Sola- 
ris operating system. Version 2.3 and higher. Solaris is 

10 a registered trademark of Sun Microsystems. Inc. 

Fig. 2 is a block dagram showing a data flow in a 
prefen-ed embodiment of the present invention. File 202 
has an associated affidavit 206 (also called a 'crypto- 
graphic Affidavit*) As a file 202 is received by the sys- 

is tarn, its affidavit Is checked against the signatures in the 
user signature data structure 120 and in the system sig- 
nature data structure 122. The file must pass both tests 
before it can be stored by the system. 

RIe 202 contains two parts: a file portion 204, 

^ which contains executable programs or data, and an 
affkJavit portion 206, which coniacna an encrypted 
checksum 210 and other admonistnative data 208. 
Administrative data 208 includes the real identity of the 
creator of the affidavit identifiers or pointers to other 

S5 associated affidavits, dates and times of creation and 
expiration of the affidavit, and identifies corners of 
the afftdaviL In some Implementations, affidavit 206 is a 
part of file 202 and in other implementations^ affidavit 
206 is a separate lite that is associated with file por^ 

sc 204. For exanrf)le« affidavit 206 can be incotporated Into 
some file fomiats as a comment line. Oth^ file formats 
may allow the affidavit to be cbsely coupled to the file 
portion 204 In some loiown manner. 

Fig. 3 shows an exanple of a signature data struc- 

3S ture of Fig. 1. Both user signature data structures and 
system signature data stmctures preferably have the 
same organizatfon, and the format of Fig. 3 is used for 
both. The user signature data structure represents 
sources that the user has Indicated are trustworthy and 

40 the system signature data structure represents sources 
that the system considers to be trustworthy- In the 
exarriple, each erttry In the signature data structure has 
a name of a (rusted entity 302. a type 304 ct the entry 
(e.g., single entry or indirect database entry], a pubfic 

^ key 306. and a series of values 308 tncSca^ng the type 
or types of permissions the entity has for tha system 
(e-g.. create, delete, read, write, execute, etc.). Every 
fae access (e.g., every file open and delete operation) is 
checked ^nst both the usa* arid system data stmc- 

so tures by the file system before the file access is allowed 
bytfiefile system. 

Figs. 4{a) and 4^) are flow charts showing how 
files are checked against the user signature data and 
the system signature data by the file system. In the pre- 

ss fened embodimerrt, all files received by the system from 
an outside source must include an affidavit. Similarly, 
each file created and stored by the file system nruist 
have an associated affidavit In soma implementatxons. 
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the affidavit is a part of the f ila In other implementa- 
tions, the affidavit is associated with thd liJa. Thus, the 
affidavit of a fife is checked whenever a fDo opflration is 
performed for the ffle. For exairple, the affidavit is 
checked when the file is created or loaded into memory. § 
The aff idavrt also is checked when the file is read from, 
written to, or deleted. $uch a process serves two goais: 
1) to protect the f 3e system from outsWers who wish to 
compromise files and 2) to protect users of the system 
from accesdno or relying on «cs that have been tam- io 
pered with. It wifj be understood by persorK of ordinary 
skill in the art that the steps erf Rgs. 4(a) and 4(b) are 
performed by CPU 102 of Rg. 1 executing Instructions 
of the file system/operating system that are stored in 
memory 104, The steps of Rgs. 4(a) and 4(b) preferably ;5 
are performed each time a file access is requested 

In step 402 of Rg 4(a), the lie system gets the 
encrypted checksum 206 associated with the ffle In 
step 404» the file system repeats the calculation of the 
checksum for the file using any known checksum sq 
method that was used to determine the affidavit Steps 
406-412 are repeated for each entry in ttie user signa- 
ture data structure (or unta a match ts found). 

In step 408, the file system decrypts the encrypted 
checksum 214 Gf the affidavft using the public key of the 25 
current user signature data structure erttry. Because the 
affidavit was created with the entiYs private key, 
decryption of the afftdavit using the entity's correct put>- 
lic key should yieki a decrypted checksum far the file. 
Decryption using other pubKc keys should yield an 30 
incorrect checksum. 

tt, in step 410, the decrypted ched«um matches 
the checksum determined in step 404, then the affidavit 
represents an entity considered trustworthy by the user 
and the fSe has not been tampered with. Thus, control 35 
passes to Rg, 4(b). If no match is found after checking 
the entire user signature data structure, than the entity 
1$ not trusted and the file operation is denied. 

St^ 420-426 are repeated for each entry in the 
system signature data structure (or until a rmtdh is 40 
found). In step 422, the file system decrypts the 
encrypted checksum 21 0 of aTtdavit 206 using the pub- 
lic key of the current system stature data structure 
entry. If, in step 424. the decrypted checksum matches 
the checksum determined In step 404, then the affidavit 
represents an entity considered taistworthy by the sys- 
tem and the file operation is altowed. If no match is 
found after cheddng the entire system signature data 
structure, then the entity is not trusted and the file oper- 
ation is denied. 5*0 

Some inrtplemontations of the present invention 
also include a *defauir entry In one or more of their slg- 
r^ture data structures. For example, as shown in Rg. 3, 
entry 320 contains the OTtity *'ariy' and allows the entity 
permission to read files. TTius. If Rg. 3 represents the ss 
user signature data structure, the user has indk^ated 
that he gives permission to ar)y entity to open a f ae in 
read-only mode. In this example, for such a ffle opera- 



tion to actually be allowed by the file system, the system 
signature data structure rmst also allow the access. In 
yet another tmplementafjon, either of the signature data 
structures rnay contain a "not entity" entry, indicating 
that a certain entity is not.anowed to make certain file 
accesses (even if an "any" entity is aJso present in one 
of the signature data structures). 

Tlie type" field of Rg. 3 allows the signature data 
structure to reference pubfic keys stored in another part 
of the system, such as in a data base or another signa- 
ture data Stnicture stored elsewhere on the computer. 
For example, users may share a common signature 
data stnjcture. Thus, in Rg. 3, the user has decided to 
allow access by the entitles owning all of the pi^ic keys 
in 'OeofTs** database. In some implementations, the 
user must be an entity trusted by Qeoffs database in 
order to access public keys therefronv 

In a preferred emtxxiiment of the present invention, 
tfie encryption scheme used is the Digital Signature 
Algorithm (DSA), described in Schneier, "Applied Cryp- 
tography: Protocols. Algorithms, and Source Code In 
C." second edition, 1996, pp. 483-495, which is herein 
incorporated by reference. In another embodiment the 
encryptk^n scheme used is the SIHA-l scheme. 

In a prefenred embodiment of the present invention, 
one or both or the user signature data structure and the 
system signature data structure are stored on a PCM* 
CIA card or some other removable storage medium. 
Thus, the user simply inserts his PCMCIA card to per- 
sonalize the user mi/or system signature data struc- 
tures of the computer that he is working oa In such an 
implementation, of course, the file system must know 
that the signature data structures are so stored. 

Rg. 5 is a flow chart of steps used to create signed 
files in a preferred embodiment of the present invention, 
whei the files are aeated by the computer system 100. 
If, for exannple, files are created on another system and 
loaded into computer system 100 via the internet or a 
floppy disk or other portable or networked media, the 
files must have already been created and must have an 
affidavit associated therewith to be accepted by compu- 
ter system 1 00. Fig, 5, however, deals with the situation 
when the user wishes to create a file on computer sys- 
tem 100. 

In step 602. the system okrtains a private key of the 
entrty creating the file. This may t>e the user's private 
key if the user Is creafng the file directly or if the user is 
mnning software that creates a file (e.g., word process- 
ing software). In a preferred embodiment, the user Is 
prompted for his private k^y and the user types his pri- 
vate key into the system or inserts a storage device on 
which his private key is stored. Alternately, private keys 
of users can be stored in a protected part off confer 
system 1 00. Alternately, a user may be required to enter 
a pin number before the system looks up the user's pri- 
vate key from a protected memory. In st^ 504, the fiie 
is created and written to storage, whae the file system 
maintains a running checksum of the data in the file. A 
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"running crTecksum" ts a checksum t^at \s continuoi^ 
update as the file is wrrtten. The system prevents file 
accesses by others while the fOd is being created. In 
some cases, portions of the file may be written to an 
external storage medium during file creatiorL Thrs situa- 
tion occurs, for example, when the created file is large. 

It should be noted that a potential pmblem can 
occur If data is written to an external storage device dur- 
ing file creation, but the file creation operation is not 
completed. In this case, data will exist on the external 
storage medium, but the data will not have an associ- 
ated afTtdaxot In a preferred embodiment, the file sys- 
tem is not allowed to access such Fdes. Aborting the 
write/creation of the file before the aflfidavft is created 
causes the system to destroy the partially written file. 

in step ^6, the ftle system encrypts the diecksum 
from step S04 using the user's private key and writes the 
checksum to the storage medium, either as a part of the 
file or associated with the file, d^ending on the imple- 
mentation. Thus, all files created by the file system of 
the described embodiment ha/e on associated affidavit 
In a prefenred eritxxfiment each time a file is wrftten to. 
its checksum must be recompute and itsafTidayit recal- 
culated using the private key of the creating entity. 
Some Implementations waft unta a Hie is closed before 
recomputing the affidavit Again, a problem can arise if 
an error occurs during the write, but before the atTdavft 
can be created and stored in association with the writ- 
ten f ila Once a file is aeated, it can only be opened or 
deleted by an entity that passes tho two-tier validation 
testof Rgs. 4(a) and 4<b}. 

In yet another embodiment, the system allows a 
user to create two types of files: verified and unverified 
files. Verified files are required to have an associated 
affidavit and are vafidated as desa^ed above for each 
file operation. Non-verified files do not require verifica- 
tion before each file operation. 

In another preferred emk>odiment, files can be 
opened (n either Verified" or unverified" mode. In this 
embodiment, the file system would most likely have two 
"open* roubnes - one that requires verificafion of files 
that It opens and one that does not 

FBes that are downloaded, e,g., over the Intemei or 
from a floppy disK retain the affidavits that they had 
when they were received by the system must be pre- 
ceded and accompanied by an affidavit. 

Fig. 6 is a bk^ck diagram of another preyed 
embodiment of the present Invention In which the m^or* 
ity of the luntime environment (e.g.. an operating sys- 
tem or interpreter) must be verified as described above 
before the system can be booted. In Fig. 6. a small 
amount of program data is stored (n a boot ROM 604. 
The CPU 602 loads a signature of the runtime environ- 
ment and basic software for coirputing a checksum and 
decrypting an affidaN^ At boot time, the remainder of 
the runtime environment is loaded from secondary 
mass storage 610, along with its affidavit (which is an 
encrypted checteum). The CPU confutes the check- 



sum of the runtime environment code as it Is loaded and 
decrypts the affidavit using the pubiic key from the boot 
ROM. If the checksum and tha decrypted ched^um 
match, the runtime environment load is completed. The 
s loaded runtime environment irKdudes the checking soft- 
ware 608. which is used as described in Figs. 4(a), 4(b). 
and 5 during operaton of the system. 

in summary, the desalbed embodiment of the 
present invention incorporates ttm or mora levels or sig- 

19 natures* A file access must satisfy both levels bafcsre it is 
allowed by the fSe system. In addition, both the user and 
the system may specify multiple trusted entities that are 
allowed to peribrm file accesses in the system. Touted 
entities are specified (ortfie system, not on a ffle by file 

IS t>asis. Various entities, however, can have various per- 
misstons associated theremth. 

Although the embodiments discussed involved 
"Yiles" a peison of oidinary skill in the art vntl understand 
that the present irventoi could also be implemented in 

20 an object oriented etwlronment 

Other embodiments wOl be apparent to those 
skilled in the art from consideration of the specification 
and practice of the invention dl&ck>sed herein. It is 
intended tfiat the specification and examples be consid- 
2S ered as exenrplary only, with a tme scope of the inven- 
6on being Indicated by the following claims and 
equivalents. 

daims 

1. A method of performing a fQe access, conprising 
the steps, performed by a data processing system 
having a memory* of: 

95 receiving an indication that an entity desires to 

perfemi a file access conation on a file of the 
data processing system: 
obtaining a cryptographic affidavit of the f Be; 
checMng that the cryptographte affidavit Is 

40 acceptable in accordance with a user signature 

data structure stored in the memory; 
checking that the cryptographic affidavit Is 
acceptable in accordance with the system sig- 
nature data structure stored in tfie memory; 

45 and 

allovnng the ffle access operation when the 
ayptc^raphic affidavit is acceptable in accord- 
ance with both the us^ signature data struc- 
ture and the system dgnature data structure. 

so 

2. The method of cfeum 1, 

wheran the receiving step {rx:Iude$ the step 
of receiving an indicatfon that a file user wishes to 
downfoadafile, 
S5 wherein the step of obtaining a crypto- 

graphic affidavit of the file includes the step of 
obtaining a cryptographfo affidavit associated with 
the file and created using a private Kay of an entity 
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that pfovidecJ the file, and 

wherein the first and second checking steps 
inctudd the steps of checking whether the entity is a 
trusted entfty for both the user and the system. 

6 

3. The method of daim 1 . 

wher^n the receiving step includes the step 
of receiving an Indication that a file user wants to 
access an existing file of the data processing sys- 
tem, and 10 

wherein the step of otjtaining a crypto- 
graphic affidavit of the ffle includes the step of 
obtaining a cryptographic affidavit associated wrth 
the file and created using a private key cf the file 
user* and 

wherein the f iret and second checking steps 
include the steps of checMng whether the file user 
is a trusted entity for both the user and the system. 

4. A method of creafing a secure f Bo, comprising the 20 
steps, performed by a data processing system hav- 
ing a memory, of: 

receiving an indication that an entity desires to 
perform a file aeate operation on a file of the 2s 
data processing system; 
obtaining a private key of the ectiSty; 
receiving data of the file to be created; 
determining a checksum of the fKe: 
encrypt the checksum using the private key: 
and 

creating tfie file and an associated crypto- 
graphic affidavft that Includes the encrypted 
checksum. 



3S 

5* A signature data structure stored in a memory of a 
data processing systenrv comprising: 

a first entity field storing a name of an entity 
tmsted to perform a fUe access: 40 
a nrst public key fieki storing a public Key of the 
first entity; 

a second entilyfield storirig a naniie of an entity 
trusted to perform a file access; and 
a second public key fiekJ storing a public key of 4S 
the second entity. 

6. The data stmclure of claim 5, further including: 

a type field indicafing that addtlonal public Key so 
infbrmatoi Is stored in a data base. 

7. The data structure cf daim 5, further including a 
first permission field* indicating one or more types 

of file access operations that can be performof by ss 
the first entity. 

8. The data structure of daim 7, further including a 



second permission field, indicating one or nrwre 
types of file access operations that can be per* 
formed by the second entity. 

9. IhB data strticture of claim 5, wherein at least one 
of the first and second entity fiefd contains a value 
of •'any*, indicating that any entity can perfbrm the 
fSe access. 

ia The data structure of claim 5, where&t at least one 
of the first and second entity field contains a value 
of "no" and a wherein at least one of the first and 
second entity field contains a permissk^n field, the 
entity field and the permission field together Indicat- 
ing that no entity can perfonn e file access opera- 
tion indicated in the permissions field. 

1 1. The data structure of claim S, further comprising a 
plurafity of first entity fields and first pUbBc key 
fieUs. 

12. The data structure of daim 11, further comprising a 
plurality of second entity fields and second pubGc 
key fields. 

13. An apparatus for perfarrning a file access, compris- 
ing: 

a memory storing a user signature data struc- 
ture and a system signature data structure; 
a user input person configured to receive an 
irKOcation that a file user desires to perform a 
file access operation on a file having an assod- 
ated cryptographic afftda^t: 
a checking porton configured to checkthat the 
cryptographic affidavit is acceptable in accord- 
ance with the user signature data structure: 
a checking portionconfigured to check that the 
cryptographic affidavit is acceptable In accord- 
ance with the system signature data structure; 
and 

a file access portion that allows the file access 
operation only whan fre cryptographk: affidavit 
is acceptable in accordance with both the user 
signature data structure and the system signa- 
ture data structure. 

14% The apparatus of claim 13. 

wherein the user input portion indudes a 
portion configured to receive an indication that a 
user wishes to download a file, arx^ 

wherein the cryptographic affidavit of the file 
was created using a private key cf an entity that 
provided the fite« and 

wher^n the first and second checking por- 
tions indude a portion configured to check whether 
the entity is a trusted entity for t»oth the user and the 
system. 
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1 5. The apparatus of daim 13. 

wherein the user input portion includes a 
pcrtion conTigured to receive an Indication that a f Oe 
user wants to access an existing f Ue on the data 
processing system, and y 

whdf din the cryptographic afTidavit was cre- 
ated using a private key of the file user, and 

wherein the first and second checking steps 
include the steps of checKng whether the file user 
is a trusted entity for IxJth the user and the system. io 

1 6- A computer program product, comprising: 

a computer usable medium having computer 
readable code embodied therein for perfarming is 
a secure fite access, the computer pro-am 
product compn'sing: 

computer readable program code devices 
configured to cause a computer to effect 20 
receiving an indication that an entity 
desires to perfonn a file access operatiort 
on a file of the data processing system; 
computer readaUe program code devices 
configured to cause a computer to effect 2s 
obtaining a cryptographic affida\^ of the 
file; 

computer readable program code devices 
configured to cause a computer to effect 
checking that the cryptogr^ic affidavit is 30 
acc^Ttable in accordance with a user ^ 
nature data structure stored in the storage 
medium: 

computer readable program code devices 
configured to cause a computer to effect 3$ 
checking that the cryptographic arwJavit is 
acceptable in accordance with the system 
signature data structure stored in the stor- 
age medium; and 

computer readable program code devices 4q 
configured to cause a computer to effect 
allowing the file access operation when the 
cryptographic affidayit is acceptable In 
accordarkce whh both the user signature 
data structure and the system signature 49 
data structure. 

17. A computer program product, comprising: 

a computer usable medium having computer so 
readable code embodied therein for performing 
a file access, the computer program product 
comprisb^: 

computer readable program code devices ss 
configured to cause a computer to effect 
receiving an indication that an entity 
desires to perform a file access operation 



on a file of the data processing system: 
computer readable program code deuces 
contigured to causa a computer to effect 
obtaining a private key of the entity; 
computer readable program code devices 
configured to cause a computer to effect 
receiving data of the file to be created; 
computer readable program code devices 
configured to cause a computer to effect 
determining a checksum of the fSe; 
computer readable program code devices 
configured to cause a computer to effect 
encrypting the checksum using fha private 
key; and 

conputer readabia program code 
devices configured to cause a compu- 
ter to effect creating the file and an 
associated cryptographic affidavit that 
Includes the encrypted checksum. 
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